@smarterclayton Take a look.
One note: I'm displaying context name AND project name, but not server and user. From the config file I don't know which username I am, one idea is to fetch it with a call to Users().Get(~), but it would make osc project <context> call the server. And I think just printing the authInfo name does not make much sense (authInfo.name can be the username, but not necessarily will be).
Any preference?

If they provided a username show it, otherwise don't. We may want to store that info in the context eventually but for now it's fine to not have it.

----- Original Message -----

@smarterclayton Take a look.
One note: I'm displaying context name AND project name, but not server and
user. From the config file I don't know which username I am, one idea is to
fetch it with a call to Users().Get(~), but it would make osc project <context> call the server. And I think just printing the authInfo name
does not make much sense (authInfo.name can be the username, but not
necessarily will be).
Any preference?

---

Reply to this email directly or view it on GitHub:
#1405 (comment)

@smarterclayton All comments addressed. I'm showing the server, but never the username - they are not supposed to provide --username to this command (I have a TODO to de-register --username and --password for every command other than login).

AND looks like stuff changed and I have to rebase. :)

Rebased.

@smarterclayton Fixed the latest comments.

Let me try it out.

$ osc project foo
Using server "https://localhost:8443".
Now using project "foo" from context named "b4596c40-d1b5-11e4-b7f8-7831c1b76042".

Should be using "foo" as the context name (by default) and the message should be

"Now using project "foo" on server https://localhost:8443"

because context name == project name. Don't need two lines for server.

----- Original Message -----

@smarterclayton Fixed the latest comments.

---

Reply to this email directly or view it on GitHub:
#1405 (comment)

$ osc project foo
Using server "https://localhost:8443".
Now using project "foo" from context named "b4596c40-d1b5-11e4-b7f8-7831c1b76042".

$ osc project bar
Using server "https://localhost:8443".
Now using project "bar" from context named "fc10fe66-d1b5-11e4-b654-7831c1b76042".

$ osc project foo
Using server "https://localhost:8443".
Now using project "foo" from context named "fd1e107a-d1b5-11e4-9b48-7831c1b76042".

The last one should be using the context name from the first time (which should be foo, but it looks like it's generating a new one every time)

1. Clean slate (no contexts)
2. osc project foo
3. Have one context "foo" pointing to project "foo"
4. osc project bar
5. Have two contexts "foo" and "bar" pointing to those projects
6. osc project bar --server=
7. should create a new context "bar-" pointing to project bar on that server (if i have a single cluster with that server name)
8. osc project bar --cluster=
9. should create a new context "bar-" pointing to project bar on that server
10. osc project bar --context=
11. if context name does not exist, it should create it pointing to that project. otherwise, if the context already exists pointing to a different project and different server, it should give me an error.

I don't think you need to implement 6-9 here, but eventually we'll need to be able to do that.

----- Original Message -----

$ osc project foo
Using server "https://localhost:8443".
Now using project "foo" from context named
"b4596c40-d1b5-11e4-b7f8-7831c1b76042".

Should be using "foo" as the context name (by default) and the message should
be

"Now using project "foo" on server https://localhost:8443"

because context name == project name. Don't need two lines for server.

----- Original Message -----

@smarterclayton Fixed the latest comments.

---

Reply to this email directly or view it on GitHub:
#1405 (comment)

@smarterclayton Most issues have been addressed, please give it a try.

I also integrated the context identifier generator between project and login that will now use the same logic. Will try to generate the best identifier possible with the information available, removing unwanted characters like :./. Will result into something like this (in order, subsequent ones will be used when previous ones are taken):

foo
foo-localhost
foo-localhost-8443
foo-localhost-8443-username
foo-localhost-8443-username-0
foo-localhost-8443-username-1
(...)
UUID if nothing else works

When would uid be necessary?

On Mar 24, 2015, at 12:45 AM, Fabiano Franz notifications@github.com wrote:

@smarterclayton Most issues have been addressed, please give it a try.

I also integrated the context identifier generator between project and login that will now use the same logic. Will try to generate the best identifier possible with the information available, removing unwanted characters like :./. Will result into something like this (in order, subsequent ones will be used when previous ones are taken):

foo
foo-localhost
foo-localhost-8443
foo-localhost-8443-username
foo-localhost-8443-username-0
foo-localhost-8443-username-1
(...)
UUID if nothing else works
—
Reply to this email directly or view it on GitHub.

Most likely never, but if every other 104 context identifiers we tried to generate are taken, we need something to be the context identifier.

----- Original Message -----

When would uid be necessary?

On Mar 24, 2015, at 12:45 AM, Fabiano Franz notifications@github.com
wrote:

@smarterclayton Most issues have been addressed, please give it a try.

I also integrated the context identifier generator between project and
login that will now use the same logic. Will try to generate the best
identifier possible with the information available, removing unwanted
characters like :./. Will result into something like this (in order,
subsequent ones will be used when previous ones are taken):

foo
foo-localhost
foo-localhost-8443
foo-localhost-8443-username
foo-localhost-8443-username-0
foo-localhost-8443-username-1
(...)
UUID if nothing else works
—
Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub:
#1405 (comment)

I think in that case it would be ok to bail and report an error to the user that they need to provide a context name on the CLI

----- Original Message -----

Most likely never, but if every other 104 context identifiers we tried to
generate are taken, we need something to be the context identifier.

----- Original Message -----

When would uid be necessary?

On Mar 24, 2015, at 12:45 AM, Fabiano Franz notifications@github.com
wrote:

@smarterclayton Most issues have been addressed, please give it a try.

I also integrated the context identifier generator between project and
login that will now use the same logic. Will try to generate the best
identifier possible with the information available, removing unwanted
characters like :./. Will result into something like this (in order,
subsequent ones will be used when previous ones are taken):

foo
foo-localhost
foo-localhost-8443
foo-localhost-8443-username
foo-localhost-8443-username-0
foo-localhost-8443-username-1
(...)
UUID if nothing else works
—
Reply to this email directly or view it on GitHub.

---

Reply to this email directly or view it on GitHub:
#1405 (comment)

---

Reply to this email directly or view it on GitHub:
#1405 (comment)

LGTM [merge] - follow ups opened as issues.

@smarterclayton Just fixed your latest comment.

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_openshift3/1283/) (Image: devenv-fedora_1126)

Evaluated for origin up to 4318ad1